![[Amazon FSx for NetApp ONTAP] スループットキャパシティがボリュームバックアップからのリストア速度に影響を与えるのか確認してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
[Amazon FSx for NetApp ONTAP] スループットキャパシティがボリュームバックアップからのリストア速度に影響を与えるのか確認してみた
2025.01.19どの程度リストアに時間がかかるのか気になる
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)のボリュームバックアップにどのぐらい時間がかかるのか気になったこと思ったことはありますか? 私はあります。
FSxNのボリュームバックアップからのリストアはEBSスナップショットからのリストアのように、即時でリストアが完了し、データブロックにアクセスがあったタイミングでS3からデータブロックを取得してくるようなアーキテクチャではありません。
そのため、ボリュームがリストア完了するまで読み書きできません。(第二世代ファイルシステムの場合はリストア中でも読み取りは可能です)。
第 ONTAP2 世代のファイルシステムの FSx でバックアップを復元する場合、クライアントは復元中にボリュームからデータをマウントして読み取ることができます。クライアントは、Amazon がすべてのメタデータを新しいボリュームにFSxロードし、ボリュームが のライフサイクルステータスを報告すると、復元するボリュームをマウントしてファイルデータを読み取ることができますCREATED。ボリュームのライフサイクル状態は、Amazon FSxコンソールのボリュームの詳細ページと describe-volumes CLI コマンドのレスポンスで確認できます。
バックアップから復元されている間にボリュームからデータを読み取るときに、データがボリュームにまだダウンロードされていない場合、最初のアクセスには最大数十 ミリ秒の読み込みレイテンシーが発生します。これらの読み取りは SSD 階層にキャッシュされ、それ以降の読み取りにはミリ秒未満の読み取りレイテンシーが予想されます。
Amazon がボリュームFSxを読み取り専用アクセス可能にするのにかかる時間は、バックアップに保存されているファイルメタデータの量に比例します。ファイルメタデータは通常、データセットの平均ファイルサイズに応じてバックアップデータの 1～7% を消費します (小さなファイルデータセットは、大きなファイルデータセットよりも多くのメタデータを消費します)。
ということで、リストア速度が気になりますよね。リストアが完了するまでの時間 > RTO です。
過去以下記事で48GiB程度のファイルでリストアした経験はあり、その時は7分ほどで完了しました。
AWS 公式ドキュメントには以下のようにバックアップとリストア速度の目安が記載されていました。
一般的に、SSDストレージ階層に保存されているデータをバックアップする場合、次のバックアップレートが期待できます。
- 大部分が大きなファイルを含む複数の同時バックアップMBpsで 750。
- ほとんど小さなファイルを含む複数の同時バックアップMBpsで 100 個。
一般に、次の復元速度が期待できます。
- 主に大きなファイルを含む複数の同時復元MBpsで 250 個。
- ほとんど小さなファイルを含む複数の同時復元MBpsで 100 個。
ファイルサイズの大きい、小さいの基準は不明ですが、リストアは100〜250MBpsが目安になりそうです。
また、AWS公式ドキュメントには、バックアップおよびリストアをする際は未使用のスループットキャパシティ分を用いると記載がありました。
バックアップおよび復元操作の速度には、さまざまな要因が影響する可能性があります。バックアッ操作と復元操作はバックグラウンドプロセスであるため、クライアント IO 操作よりも優先度が低くなります。クライアント IO オペレーションにはNFS、、CIFS、および iSCSI データおよびメタデータの読み取りと書き込みが含まれます。すべてのバックグラウンド操作では、ファイルシステムのスループットキャパシティの未使用部分のみが利用されます。バックアップのサイズとファイルシステムの未使用スループットキャパシティの量によっては、完了までに数分から数時間かかる場合があります。
つまりは、リストアする際キャパシティプールストレージを拡張すれば速度が向上しそうです。
実際に試してみます。
いきなりまとめ
- 検証の結果、クライアントアクセスなど、他処理を行っていない状況においては、スループットキャパシティがリストア速度に与えるはそこまで大きくないように見える
- 128MBps : 1時間26分 (159MiBps)
- 256MBps : 56分 (243MiBps)
- 512MBps : 1時間16分 (180MiBps)
- ただし、階層化の速度やFSxNファイルシステムに与える負荷には大きな影響を与える
- リストア中は基本的にネットワークスループットおよびディスクスループット、ディスクIOPS、CPUをフル活用する
- スループットキャパシティが小さい場合はバーストも発生する
- リストア中は基本的にネットワークスループットおよびディスクスループット、ディスクIOPS、CPUをフル活用する
- 検証した限り、スループットキャパシティが128MBpsや256MBpsでTiering Policy Allの場合のリストア時に求められるSSDの空き容量は、バッファを加味するとリストアボリューム内のデータ量の7~8割ぐらいあるのが望ましい
- 5割程度しか空きがない場合はSSD不足でエラーになる可能性が高いと予想
- SSDは減らすことはできまないため。リストア時にSSDの空きが少ないからといって、SSDを増やしてしまうと、今後増強したSSDのコストを払い続ける必要がある
- リストア時はスループットキャパシティを512MBps以上にしてあげ、スムーズに階層化が進むようにしてあげる方がトータルコストが安くなる可能性がある
やってみた
使用量が800GiBのボリュームの用意
まず、ボリュームを作成します。
マネジメントコンソールで2TiBのボリュームを作成しました。
Storage Efficiencyを有効化すると影響度合いが分かりにくくなるので無効化しています。
なお、以下記事で紹介しているとおり、Storage Efficiency(TSSE含む)によって重複排除、圧縮、データコンパクションが発生していたとしても、リストアされたデータはその効果を維持されていません。
FSxNファイルシステムは以下のとおりです。スループットキャパシティを512MBpsとしています。
ボリューム作成後、EC2インスタンスからこちらのボリュームをマウントします。
なお、こちらのEC2インスタンスのインスタンスタイプはc7i.largeです。
sh-5.2$ sudo mkdir -p /mnt/fsxn/vol_backup_test
sh-5.2$ sudo mount -t nfs svm-04f22e3a82142d131.fs-0e64a4f5386f74c87.fsx.us-east-1.amazonaws.com:/vol_backup_test /mnt/fsxn/vol_backup_test
sh-5.2$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-04f22e3a82142d131.fs-0e64a4f5386f74c87.fsx.us-east-1.amazonaws.com:/vol_backup_test nfs4 2.0T 1.2T 771G 61% /mnt/fsxn/vol_backup_test
ファイルを書き込む前にボリュームやaggregateの状態を確認しておきます。
::> version
NetApp Release 9.14.1P9: Mon Oct 21 18:04:05 UTC 2024
::> set advanced
Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you want to continue? {y|n}: y
::*> aggr show -fields availsize, usedsize, size, physical-used, physical-used-percent, data-compaction-space-saved, data-compaction-space-saved-percent, data-compacted-count, composite-capacity-tier-used, sis-space-saved, sis-space-saved-percent, sis-shared-count, inactive-data-reporting-start-timestamp
aggregate availsize size usedsize physical-used physical-used-percent data-compaction-space-saved data-compaction-space-saved-percent data-compacted-count composite-capacity-tier-used sis-space-saved sis-space-saved-percent sis-shared-count inactive-data-reporting-start-timestamp
--------- --------- ------- -------- ------------- --------------------- --------------------------- ----------------------------------- -------------------- ---------------------------- --------------- ----------------------- ---------------- ---------------------------------------
aggr1 770.2GB 861.8GB 91.57GB 99.32GB 11% 192KB 0% 80KB 40.69GB 192KB 0% 80KB -
::*> volume show-footprint -volume vol_backup_test
Vserver : svm
Volume : vol_backup_test
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 308KB 0%
Footprint in Performance Tier 1.85MB 100%
Footprint in FSxFabricpoolObjectStore 0B 0%
Volume Guarantee 0B 0%
Flexible Volume Metadata 112.1MB 0%
Delayed Frees 1.55MB 0%
File Operation Metadata 4KB 0%
Total Footprint 113.9MB 0%
Effective Total Footprint 113.9MB 0%
それでは用意したボリューム内にファイルを書き込みます。
ファイルは16GiBのファイルを50個用意します。つまり、合計800GiBです。
$ for i in {1..50}; do
echo "Creating file ${i}/50..."
sudo dd if=/dev/urandom \
of="/mnt/fsxn/vol_backup_test/random_pattern_binary_block_16GiB_${i}" \
bs=1M \
count=16384 \
status=progress
done
Creating file 1/50...
17027825664 bytes (17 GB, 16 GiB) copied, 47 s, 362 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 50.1793 s, 342 MB/s
Creating file 2/50...
16979591168 bytes (17 GB, 16 GiB) copied, 47 s, 361 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 48.0928 s, 357 MB/s
Creating file 3/50...
16816013312 bytes (17 GB, 16 GiB) copied, 57 s, 295 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 58.5627 s, 293 MB/s
Creating file 4/50...
17062428672 bytes (17 GB, 16 GiB) copied, 50 s, 341 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 50.8876 s, 338 MB/s
Creating file 5/50...
16937648128 bytes (17 GB, 16 GiB) copied, 45 s, 376 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 46.464 s, 370 MB/s
Creating file 6/50...
16994271232 bytes (17 GB, 16 GiB) copied, 45 s, 378 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 46.3701 s, 370 MB/s
.
.
(以下略)
.
.
300MBps〜380MBps程度出せていますね。
しかし、30分ほど経つと、スループットが200MBps程度に落ち着いてきました。
.
.
(略)
.
.
Creating file 30/50...
17034117120 bytes (17 GB, 16 GiB) copied, 83 s, 205 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 87.4402 s, 196 MB/s
Creating file 31/50...
16914579456 bytes (17 GB, 16 GiB) copied, 84 s, 201 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 88.4409 s, 194 MB/s
Creating file 32/50...
17073963008 bytes (17 GB, 16 GiB) copied, 87 s, 196 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 91.3683 s, 188 MB/s
.
.
(略)
.
.
CloudWatchメトリクスを眺めていると、ネットワークスループットとディスクスループットが100%周辺を推移し始めました。
特にネットワークスループットはバーストしていたようで、ファイルを作成し始めてから30分間ほど100%を超過していました。これはネットワークスループットのバーストクレジットを使い切った可能性が高そうです。
なお、どの程度バーストクレジットが残っているのかを表すCloudWatchメトリクスは2025/1/18時点では存在しないので、あくまで推測です。
200MBpsといっても高速だとは思うので、このまま放置しましょう。
しかし、さらに30分ほど経つと、スループットが100MBps程度になってしまいました。
.
.
(略)
.
.
Creating file 39/50...
17086545920 bytes (17 GB, 16 GiB) copied, 170 s, 101 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 177.868 s, 96.6 MB/s
Creating file 40/50...
17179869184 bytes (17 GB, 16 GiB) copied, 171 s, 100 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 177.857 s, 96.6 MB/s
Creating file 41/50...
17086545920 bytes (17 GB, 16 GiB) copied, 170 s, 101 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 177.839 s, 96.6 MB/s
.
.
(略)
.
.
FSxNのメトリクスを確認してもネットワークスループット、およびディスクスループット、ディスクIOPSのいずれも余裕はありそうです。
ということで、EC2インスタンスのメトリクスも確認してみると、こちらも落ち込んでいます。
もしかすると、EC2インスタンス側でネットワークのバーストクレジットを使い切ったのかもしれません。
c7i.largeのネットワークのベースラインスループットは0.781Gbpsです。
よりネットワーク帯域が太いc6in.xlargeに変更します。
c6in.xlargeはネットワークのベースラインスループットは6.25Gbpsです。インスタンスタイプごとのネットワークやEBSのベースラインスループットは以下から確認可能です。
インスタンスタイプ変更後は以下のようにコンスタントに350MBps程度を出せるようになりました。
$ for i in {43..50}; do
echo "Creating file ${i}/50..."
sudo dd if=/dev/urandom \
of="/mnt/fsxn/vol_backup_test/random_pattern_binary_block_16GiB_${i}" \
bs=1M \
count=16384 \
status=progress
done
Creating file 43/50...
16896753664 bytes (17 GB, 16 GiB) copied, 47 s, 359 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 49.0898 s, 350 MB/s
Creating file 44/50...
17098080256 bytes (17 GB, 16 GiB) copied, 67 s, 255 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 74.6702 s, 230 MB/s
Creating file 45/50...
17171480576 bytes (17 GB, 16 GiB) copied, 47 s, 365 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 48.4294 s, 355 MB/s
Creating file 46/50...
17079205888 bytes (17 GB, 16 GiB) copied, 49 s, 349 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 51.7907 s, 332 MB/s
Creating file 47/50...
16957571072 bytes (17 GB, 16 GiB) copied, 66 s, 257 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 68.7127 s, 250 MB/s
Creating file 48/50...
17116954624 bytes (17 GB, 16 GiB) copied, 47 s, 364 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 49.8827 s, 344 MB/s
Creating file 49/50...
17151557632 bytes (17 GB, 16 GiB) copied, 47 s, 365 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 49.8416 s, 345 MB/s
Creating file 50/50...
16873684992 bytes (17 GB, 16 GiB) copied, 48 s, 352 MB/s
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 51.8623 s, 331 MB/s
ファイルを書き終えたようなので、確かに800GiB書き込み完了したのか確認します。
$ df -hT -t nfs4
Filesystem Type Size Used Avail Use% Mounted on
svm-04f22e3a82142d131.fs-0e64a4f5386f74c87.fsx.us-east-1.amazonaws.com:/vol_backup_test nfs4 2.0T 1.2T 756G 62% /mnt/fsxn/vol_backup_test
$ du -sh /mnt/fsxn/vol_backup_test
804G /mnt/fsxn/vol_backup_test
完了していますね。
ONTAP CLIからも確認します。
::*> aggr show -fields availsize, usedsize, size, physical-used, physical-used-percent, data-compaction-space-saved, data-compaction-space-saved-percent, data-compacted-count, composite-capacity-tier-used, sis-space-saved,sis-space-saved-percent, sis-shared-count, inactive-data-reporting-start-timestamp
aggregate availsize size usedsize physical-used physical-used-percent data-compaction-space-saved data-compaction-space-saved-percent data-compacted-count composite-capacity-tier-used sis-space-saved sis-space-saved-percent sis-shared-count inactive-data-reporting-start-timestamp
--------- --------- ------- -------- ------------- --------------------- --------------------------- ----------------------------------- -------------------- ---------------------------- --------------- ----------------------- ---------------- ---------------------------------------
aggr1 726.2GB 861.8GB 135.6GB 189.8GB 21% 192KB 0% 80KB 838.7GB 192KB 0% 80KB -
::*> volume show-footprint -volume vol_backup_test
Vserver : svm
Volume : vol_backup_test
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 809.7GB 89%
Footprint in Performance Tier 9.85GB 1%
Footprint in FSxFabricpoolObjectStore
805.0GB 99%
Volume Guarantee 0B 0%
Flexible Volume Metadata 4.57GB 1%
Delayed Frees 5.13GB 1%
File Operation Metadata 4KB 0%
Total Footprint 819.4GB 90%
Effective Total Footprint 819.4GB 90%
::*> volume show -volume vol_backup_test -fields available, size, percent-used, logical-used, logical-used-percent, used
vserver volume size available used percent-used logical-used logical-used-percent
------- --------------- ---- --------- ------- ------------ ------------ --------------------
svm vol_backup_test 2TB 726.2GB 809.7GB 41% 809.7GB 42%
800GiBのうち、ほとんどのデータがキャパシティプールストレージに書き込まれていることが分かります。
書き込み完了後の各種メトリクスを確認します。
FSxのコンソールからFSxNファイルシステムのメトリクスで、パフォーマンスを選択した際は以下のようなメトリクスを確認できます。
ネットワーク、ディスク、IOPSをフル活用していたことが分かります。CPU的にはまだまだ余裕はありそうです。
なお、ネットワークスループットやディスクスループットで0に落ち込んでいるのはスクリプトを実行しているEC2インスタンスとのセッションが切れた時や、インスタンスタイプを変更している時です。
ネットワークスループットの使用率を拡大すると以下のとおりです。
FSxのコンソールからFSxNファイルシステムのメトリクスで、概要を選択した際は以下のようなメトリクスを確認できます。Tiering PolicyをAllにしていたので、プライマリストレージ = SSDをほとんど消費していないことが分かりますね。
ファイルを書き込んだボリュームのメトリクスは以下のとおりです。こちらからもクライアントスループットやクライアントIOPSを確認できます。
合計クライアントスループットのグラフはFSxNファイルシステムのメトリクスと一致していますね。
EC2インスタンスのメトリクスは以下のとおりです。
ボリュームのバックアップ
それではボリュームのバックアップを行います。
バックアップはFSxのコンソールからではなく、AWS Backupのコンソールからオンデマンドバックアップで行います。
AWS Backupでオンデマンドバックアップを開始すると、FSxのコンソールからでもバックアップが開始されたことを確認できました。
16分ほどでバックアップが完了しました。800GiBで16分ということは単純計算で853MiBpsです。速いです。AWS公式ドキュメントでは750MBpsと記載があったため、かなり上振れていますね。
FSxのコンソールからバックアップの取得が完了していることを確認できました。
バックアップ取得時の各種メトリクスを確認してみましょう。
まずはFSxNファイルシステムのパフォーマンスのメトリクスです。
13:28がバックアップ取得のタイミングです。13:00と14:00の中間ほどをみると、ネットワークスループットとCPU使用率が跳ねていることが分かりますね。またディスクIOPSも若干伸びています。
ネットワークスループットやCPU使用率を大きく使用するということは、スループットキャパシティの影響を大きく受けそうです。
続いてFSxNファイルシステムの概要のメトリクスです。
SSDの使用量はほとんど変わりありません。また、クライアントスループットおよびクライアントIOPSは動いていないことから、バックアップがバックグラウンドプロセスであることが分かります。
最後にバックアップ時のBytes関連のメトリクスを確認します。
NetworkSentBytes、NetworkReceivedBytes、CapacityPoolReadBytesが跳ねていることが分かります。つまり、キャパシティプールストレージの読み込んで転送しているということですね。
ボリュームのリストア (スループットキャパシティ512MBps)
本命のボリュームのリストアを行っていきましょう。
先ほど取得した復旧ポイント(バックアップ)を選択して、リストアします。
リストア時のパラメーターはボリューム名とジャンクションパス以外はオリジナルのボリュームと全く同じです。
リストアが開始されました。
リストア中のストレージ使用量のメトリクスを覗いてみましょう。
それぞれのメトリクスは以下のとおりです。
- 赤 : FSxNファイルシステム全体のストレージ使用量
- 緑 : FSxNファイルシステム全体のキャパシティプールストレージの使用量
- 青 : FSxNファイルシステム全体のSSDのサイズ
- 橙 : FSxNファイルシステム全体のSSDの使用量
- 茶 : リストア中のボリュームのキャパシティプールストレージの使用量
- 紫 : リストア中のボリュームのSSDの使用量
橙や紫のメトリクスが伸び図、緑や茶のメトリクスが伸びていることから、SSDはほとんど圧迫されず、キャパシティプールストレージにどんどん階層化されていっていることが分かります。
これであれば、SSDの空き容量が少なくともリストアできそうです。
リストア中のBytes関連のメトリクスを確認します。
Read系以外は満遍なく、転送および書き込みが発生していることが分かります。
FSxNファイルシステムのパフォーマンスのメトリクスも確認します。
リストアは14:13に開始したので、14:00以降に跳ねているところを見ます。
ネットワークスループットとディスクスループット、ディスクIOPS、CPU使用率が伸びています。ただ、ネットワークスループットは100%を超過していないことからバックアップ時と異なり、バーストは発生していなさそうです。
また、ディスクスループット(FileServerDiskThroughputUtilization)、ディスクIOPS(FileServerDiskIopsUtilizationもしくはDiskIopsUtilization)はいずれもFSxNのノードとSSD間のやりとりについてのメトリクスです。
バックアップ時は直接キャパシティプールから読み込んでいましたが、リストア時はSSDにも書き込まれるため、これらメトリクスが跳ねています。
続いてFSxNファイルシステムの概要のメトリクスです。
リストアがバックグラウンドプロセスであるためクライアントスループット、クライアントIOPSで計測されないことを確認できます。また、SSDの空き容量も大きく変動はありませんね。
1時間16分ほど待つとリストアが完了しました。
データ転送の開始前後にオーバーヘッド等はあるとは思いますが、データ転送速度は単純計算で180MBpsです。AWS公式ドキュメントではリストア時のデータ転送速度は100〜250MBpsが目安とあったので、目安の範囲内に収まっています。
リストアボリュームのメトリクスは以下のとおりです。キャパシティプールストレージのIOPSが跳ねていますね。リストアでどんどん階層化している影響でしょう。
FSxNファイルシステムのパフォーマンスのメトリクスも確認します。
バーストはしていないもののネットワークスループット、ディスクスループット、ディスクIOPSは常に100%近い状況であることが分かります。CPU的にはまだ余裕はありそうです。
続いてFSxNファイルシステムの概要のメトリクスです。
SSDの空き容量がほとんど変化していませんね。スループットキャパシティを512MBpsにして、ボリュームリストアをシリアルで行うのであれば、バックアップによってSSDが枯渇するという心配はなさそうです。
Bytes関連のメトリクスです。
Read系以外は満遍なく、転送および書き込みが発生していることが分かります。
ストレージ使用量のメトリクスを覗いてみましょう。
はい、綺麗な線形でリストアが進んでいることが分かります。SSD使用量はリストアプロセス中に若干増加しますが、リストアが完了すると、階層化されたためか減少しています。
ボリュームのリストア (スループットキャパシティ128MBps)
スループットキャパシティが128MBpsの場合のリストア速度も確認しましょう。
スループットキャパシティを128MBpsに変更します。
30分ほどで変更完了しました。
リストアを開始します。
16:36にリストアが開始されました。
リストア中のストレージ使用量のメトリクスを覗いてみましょう。
それぞれのメトリクスは以下のとおりです。
- 赤 : FSxNファイルシステム全体のストレージ使用量
- 緑 : FSxNファイルシステム全体のキャパシティプールストレージの使用量
- 青 : FSxNファイルシステム全体のSSDのサイズ
- 橙 : FSxNファイルシステム全体のSSDの使用量
- 茶 : スループットキャパシティ512MBpsでリストアしたボリュームのキャパシティプールストレージの使用量
- 紫 : スループットキャパシティ512MBpsでリストアしたボリュームのSSDの使用量
- 桃 : スループットキャパシティ128MBpsでリストアしたボリュームのSSDの使用量
- 灰 : スループットキャパシティ128MBpsでリストアしたボリュームのキャパシティプールストレージの使用量
桃と灰のメトリクスの伸び率が拮抗しています。FSxNファイルシステム全体のSSD使用量も伸びていることから階層化処理が間に合っていないことが分かります。SSDの圧迫を避けたいのであればスループットキャパシティを512MBpsに増強するのが良さそうです。
気になるのは18:00と18:15の間で桃と灰のメトリクスが途切れ、0から再度伸び始めているところです。
リストア中のボリュームを確認してみましょう。
::*> volume show -volume vol_backup_test* -fields available, size, percent-used, logical-used, logical-used-percent, used, is-cloud-write-enabled
vserver volume size available used percent-used logical-used logical-used-percent is-cloud-write-enabled
------- --------------- ---- --------- ------- ------------ ------------ -------------------- ----------------------
svm vol_backup_test 2TB 263.8GB 809.7GB 41% 809.7GB 42% false
svm vol_backup_test_restore_128MBps
2TB 263.8GB 253.0GB 12% 253.0GB 12% false
svm vol_backup_test_restore_128MBps_1043
2TB - - - - - false
svm vol_backup_test_restore_512MBps
2TB 263.8GB 813.2GB 39% 813.2GB 40% false
4 entries were displayed.
::*> volume show-footprint -volume vol_backup_test*
Vserver : svm
Volume : vol_backup_test
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 809.8GB 89%
Footprint in Performance Tier 8.69GB 1%
Footprint in FSxFabricpoolObjectStore
806.3GB 99%
Volume Guarantee 0B 0%
Flexible Volume Metadata 4.57GB 1%
Delayed Frees 5.23GB 1%
File Operation Metadata 4KB 0%
Total Footprint 819.6GB 90%
Effective Total Footprint 819.6GB 90%
Vserver : svm
Volume : vol_backup_test_restore_128MBps
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 255.2GB 28%
Footprint in Performance Tier 105.1GB 41%
Footprint in FSxFabricpoolObjectStore
150.3GB 59%
Volume Guarantee 0B 0%
Flexible Volume Metadata 1.54GB 0%
Deduplication Metadata 320.9MB 0%
Temporary Deduplication 320.9MB 0%
Delayed Frees 282.2MB 0%
File Operation Metadata 4KB 0%
Total Footprint 257.3GB 28%
Effective Total Footprint 257.3GB 28%
Vserver : svm
Volume : vol_backup_test_restore_128MBps_1043
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 812.1GB 90%
Footprint in Performance Tier - -
Volume Guarantee 0B 0%
Flexible Volume Metadata 4.82GB 1%
File Operation Metadata 4KB 0%
Total Footprint 817.0GB 90%
Effective Total Footprint 817.0GB 90%
Vserver : svm
Volume : vol_backup_test_restore_512MBps
Feature Used Used%
-------------------------------- ---------- -----
Volume Data Footprint 813.2GB 90%
Footprint in Performance Tier 15.34GB 2%
Footprint in FSxFabricpoolObjectStore
800GB 98%
Volume Guarantee 0B 0%
Flexible Volume Metadata 4.57GB 1%
Deduplication Metadata 1.23GB 0%
Deduplication 1.23GB 0%
Delayed Frees 2.18GB 0%
File Operation Metadata 4KB 0%
Total Footprint 821.1GB 91%
Effective Total Footprint 821.1GB 91%
4 entries were displayed.
vol_backup_test_restore_128MBpsとvol_backup_test_restore_128MBps_1043とボリュームが2つ存在しており、vol_backup_test_restore_128MBps_1043の使用量といった情報は確認できません。もしかするとリストア途中にボリュームが削除されたのかもしれません。
該当時間帯の管理アクティビティの監査ログを眺めてみます。
::*> security audit log show -fields timestamp, node, application, vserver, username, input, state, message -timestamp >"Sat Jan 18 09:00:00 2025" -state Error|Success
timestamp node application vserver username input state message
-------------------------- ------------------------- ----------- ---------------------- ----------------- ---------------------------------------------------------------------------------------------------------------------------------- ------- -------
"Sat Jan 18 09:00:52 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/storage/volumes/243c80dc-a8aa-11ef-accd-b31c82a68aa5/snapshots?return_records=true : {"name":"backup-04114aa9b73471e7e"} Success -
"Sat Jan 18 09:01:03 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success -
"Sat Jan 18 09:01:03 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/snapmirror/relationships/6eee9a94-a8ad-11ef-accd-b31c82a68aa5/transfers : isv_name="AWS FSx" Success -
"Sat Jan 18 09:01:03 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/snapmirror/relationships/6eee9a94-a8ad-11ef-accd-b31c82a68aa5/transfers?return_records=true : {"source_snapshot":"backup-04114aa9b73471e7e"}
Success -
"Sat Jan 18 09:04:44 2025" FsxId0e64a4f5386f74c87-01 ssh FsxId0e64a4f5386f74c87 fsx-control-plane set -privilege diagnostic Success -
"Sat Jan 18 09:04:44 2025" FsxId0e64a4f5386f74c87-01 ssh FsxId0e64a4f5386f74c87 fsx-control-plane volume efficiency inactive-data-compression stop -volume vol_backup_test_restore_128MBps -vserver svm Success -
"Sat Jan 18 09:04:44 2025" FsxId0e64a4f5386f74c87-01 ssh FsxId0e64a4f5386f74c87 fsx-control-plane Logging out Success -
"Sat Jan 18 09:04:44 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/private/cli : {"input":"set -privilege diagnostic ; volume efficiency inactive-data-compression stop -volume vol_backup_test_restore_128MBps -vserver svm"}
Success -
"Sat Jan 18 09:04:44 2025" FsxId0e64a4f5386f74c87-01 ssh FsxId0e64a4f5386f74c87 fsx-control-plane set -privilege diagnostic Success -
"Sat Jan 18 09:04:44 2025" FsxId0e64a4f5386f74c87-01 ssh FsxId0e64a4f5386f74c87 fsx-control-plane volume efficiency inactive-data-compression modify -volume vol_backup_test_restore_128MBps -vserver svm -is-enabled false Success -
"Sat Jan 18 09:04:44 2025" FsxId0e64a4f5386f74c87-01 ssh FsxId0e64a4f5386f74c87 fsx-control-plane Logging out Success -
"Sat Jan 18 09:04:44 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/private/cli : {"input":"set -privilege diagnostic ; volume efficiency inactive-data-compression modify -volume vol_backup_test_restore_128MBps -vserver svm -is-enabled false"}
Success -
"Sat Jan 18 09:04:45 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane PATCH /api/storage/volumes/a176021a-d56f-11ef-a731-0965ba6a09bf : {"tiering":{"policy":"ALL"},"nas":{"path":"/vol_backup_test_restore_128MBps"},"efficiency":{"compression":"none","compaction":"none","dedupe":"none","cross_volume_dedupe":"none"},"snapshot_policy":{"name":"default"}}
Success -
"Sat Jan 18 09:04:57 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane DELETE /api/storage/volumes/a176021a-d56f-11ef-a731-0965ba6a09bf Success -
"Sat Jan 18 09:05:09 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane DELETE /api/storage/volumes/243c80dc-a8aa-11ef-accd-b31c82a68aa5/snapshots/0dcda790-d4b1-11ef-9f43-3dac75ffb189 Success -
"Sat Jan 18 09:09:27 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/storage/volumes/?return_records=true : {"comment":"FSx.tmp.fsvol-058420ab5f77b8f06.a2ab2abe-48fa-4ff8-b895-678ab943d658","language":"c.utf_8","name":"vol_backup_test_restore_128MBps","size":2199023255552,"tiering":{"policy":"ALL"},"type":"dp","aggregates":[{"name":"aggr1","uuid":"919e6606-6063-11ef-a92a-512f30fadf39"}],"svm":{"name":"svm","uuid":"3ba0f5ee-6064-11ef-a92a-512f30fadf39"}}
Success -
"Sat Jan 18 09:09:38 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane PATCH /api/storage/volumes/eb4bbb30-d57b-11ef-a731-0965ba6a09bf : {"comment":""} Success -
.
.
(中略)
.
.
"Sat Jan 18 09:09:38 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/private/cli : {"input":"set -privilege diagnostic ; system node run -node FsxId0e64a4f5386f74c87-01 -command wafl obj_cache flush"}
Success -
.
.
(中略)
.
.
"Sat Jan 18 09:09:38 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/private/cli : {"input":"set -privilege diagnostic ; system node run -node FsxId0e64a4f5386f74c87-02 -command wafl obj_cache flush"}
Success -
"Sat Jan 18 09:09:38 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success -
"Sat Jan 18 09:09:39 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/snapmirror/relationships/?return_records=true : {"destination":{"path":"svm:vol_backup_test_restore_128MBps"},"restore":true,"source":{"path":"amazon-fsx-ontap-backup-us-east-1-3910b023-bdd6a1d0:/objstore/0c000000-026c-5606-0000-000000d0adc7_rst","uuid":"0c000000-026c-5606-0000-000000d0adc7"}}
Success -
"Sat Jan 18 09:09:39 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/snapmirror/relationships : uuid=f20f3cd8-d57b-11ef-a731-0965ba6a09bf isv_name="AWS FSx" Success -
"Sat Jan 18 09:09:39 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/cluster/licensing/access_tokens/ : {"client_secret":***,"grant_type":"client_credentials","client_id":"clientId"} Success -
"Sat Jan 18 09:09:39 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/snapmirror/relationships/f20f3cd8-d57b-11ef-a731-0965ba6a09bf/transfers : isv_name="AWS FSx" Success -
"Sat Jan 18 09:09:39 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane POST /api/snapmirror/relationships/f20f3cd8-d57b-11ef-a731-0965ba6a09bf/transfers?return_records=true : {"source_snapshot":"backup-0b4a13364528de2bb"}
Success -
"Sat Jan 18 09:25:32 2025" FsxId0e64a4f5386f74c87-01 http FsxId0e64a4f5386f74c87 fsx-control-plane GET /api/private/cli/network/interface/?fields=address%2Ccurr_node%2Chome_node%2Chome_port%2Cnetmask%2Cvserver%2Clif%2Cfailover_policy%2Cauto_revert%2Cstatus_oper%2Cstatus_admin%2Cstatus_extended
Success -
.
.
(以下略)
.
.
リストア真っ只中のSat Jan 18 09:04:57 2025とSat Jan 18 09:05:09 2025にボリュームを削除するAPIが叩かれていますね。解せないですね。
EMSイベントも確認します。
::*> event log show -time >"1/18/2025 09:00:00"
Time Node Severity Event
------------------- ---------------- ------------- ---------------------------
.
.
(中略)
.
.
1/18/2025 09:04:59 FsxId0e64a4f5386f74c87-01
INFORMATIONAL wafl.vvol.offline: Volume 'vol_backup_test_restore_128MBps@vserver:3ba0f5ee-6064-11ef-a92a-512f30fadf39' has been set temporarily offline
2 entries were displayed.
::*> event log show -time >"1/18/2025 09:00:00" -instance
.
.
(中略)
.
.
Node: FsxId0e64a4f5386f74c87-01
Sequence#: 550181
Time: 1/18/2025 09:04:59
Severity: INFORMATIONAL
EMS Severity: INFO
Source: vv_config_worker14
Message Name: wafl.vvol.offline
Event: wafl.vvol.offline: Volume 'vol_backup_test_restore_128MBps@vserver:3ba0f5ee-6064-11ef-a92a-512f30fadf39' has been set temporarily offline
Kernel Generation Number: -
Kernel Sequence Number: -
EMS Event XML Length: 371
Number of Times Suppressed Since Last Time Logged: 0
Corrective Action: (NONE)
Description: This message indicates when a virtual volume is taken offline.
2 entries were displayed.
ボリュームがオフラインになったとのメッセージはありますが、根本原因が何なのかの情報は特に記載ありません。
最終的にはDownloading of data from backup storage is paused because there is insufficient space on your file system's SSD tier. To resume downloading data on the volume, you must increase the SSD storage capacity on your file system.とSSD枯渇によりエラーになりました。
実際にリストア中に原因不明で再リストアが走り、このような事象が発生すると困ってしまいますね。
リストアボリュームはどちらも削除されていました。
::*> volume show -volume vol_backup_test*
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm vol_backup_test
aggr1 online RW 2TB 133.3GB 41%
svm vol_backup_test_restore_128MBps_1043
aggr1 offline DEL 2TB - -
svm vol_backup_test_restore_128MBps_1044
aggr1 offline DEL 2TB - -
svm vol_backup_test_restore_512MBps
aggr1 online RW 2TB 133.3GB 39%
4 entries were displayed.
リストア失敗後のFSxNファイルシステムのパフォーマンスと概要のメトリクスは以下のとおりです。
ネットワークスループットおよびディスクスループット、ディスクIOPS、CPUをフル活用していることが分かります。ディスクスループットに至ってはバーストクレジットを使っているようですね。
また、SSDの空き容量がリストアプロセスが進む中でみるみる減少していることも分かります。
ボリュームの再リストア (スループットキャパシティ128MBps)
非常に中途半端な結果になってしまったので、スループットキャパシティ128MBpsで再度トライします。
現在、SSDの空き容量が非常に少ないです。
これは削除されたボリュームがリカバリーキューに残り続けており、データの削除処理が進んでいないためです。リカバリーキューについては以下記事をご覧ください。
リカバリーキュー内のボリュームを削除します。
::*> volume recovery-queue show
Vserver Volume Deletion Request Time Retention Hours
--------- ----------- ------------------------ ---------------
svm vol_backup_test_restore_128MBps_1043
Sat Jan 18 09:04:59 2025 12
svm vol_backup_test_restore_128MBps_1044
Sat Jan 18 10:24:20 2025 12
2 entries were displayed.
::*> volume recovery-queue purge-all -vserver svm
[Job 2031] Job succeeded: Successful
::*> volume show -volume vol_backup_test*
Vserver Volume Aggregate State Type Size Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
svm vol_backup_test
aggr1 online RW 2TB 205.1GB 41%
svm vol_backup_test_restore_512MBps
aggr1 online RW 2TB 205.1GB 39%
2 entries were displayed.
リカバリーキュー内のボリュームの削除をすると、みるみるaggregateのSSD使用量が減っていくことが分かります。
::*> aggr show -fields availsize, usedsize, size, physical-used, physical-used-percent
aggregate availsize size usedsize physical-used physical-used-percent
--------- --------- ------- -------- ------------- ---------------------
aggr1 576.4GB 861.8GB 285.3GB 357.7GB 39%
::*> aggr show -fields availsize, usedsize, size, physical-used, physical-used-percent
aggregate availsize size usedsize physical-used physical-used-percent
--------- --------- ------- -------- ------------- ---------------------
aggr1 621.3GB 861.8GB 240.4GB 277.8GB 31%
::*> aggr show -fields availsize, usedsize, size, physical-used, physical-used-percent
aggregate availsize size usedsize physical-used physical-used-percent
--------- --------- ------- -------- ------------- ---------------------
aggr1 732.0GB 861.8GB 129.8GB 131.3GB 14%
これはCloudWatchメトリクスからでも確認できます。
SSDの空きを確保できたので、再度リストアします。
リストアは1時間26分で完了しました。スループットキャパシティが512MBpsの場合は1時間16分だったので、思ったよりも大きの差ではありません。
リストアボリュームのメトリクスは以下のとおりです。
SSD使用率が減り続け、ある程度のタイミングで増え始めています。
FSxNファイルシステムの概要のメトリクスでも同様の内容を読み取れます。
FSxNファイルシステムのパフォーマンスのメトリクスは以下のとおりです。
1回目のリストアと同様に、ネットワークスループットおよびディスクスループット、ディスクIOPS、CPUをフル活用していることが分かります。
ストレージ使用量の推移は以下のとおりです。
注目すべきはメトリクスは以下のとおりです。
- 赤 : FSxNファイルシステム全体のストレージ使用量
- 緑 : FSxNファイルシステム全体のキャパシティプールストレージの使用量
- 青 : FSxNファイルシステム全体のSSDのサイズ
- 水 : スループットキャパシティ128MBpsでリストアしたボリュームのキャパシティプールストレージの使用量
- 黄 : スループットキャパシティ128MBpsでリストアしたボリュームのSSDの使用量
水と黄のメトリクスが同じスピードで増加していることが分かります。そして、リストアデータをSSDかキャパシティプールストレージのいずれかの階層に書き切ったタイミングで、SSDに残っているデータをキャパシティプールへ階層化していることが分かります。
スループットキャパシティが128MBpsでTiering Policy Allの場合のリストア時に求められるSSDの空き容量は、バッファを加味するとリストアボリューム内のデータ量の7~8割ぐらいあると良いでしょう。5割程度しか空きがない場合はSSD不足でエラーになる可能性が高いでしょう。
ボリュームのリストア (スループットキャパシティ256MBps)
スループットキャパシティが512MBpsの場合はほぼSSDを圧迫せずにリストアできました。
一方、128MBpsの場合は、階層化が間に合わず、SSDにもある程度余裕が要求されることを確認しました。
では、間の256MBpsの場合はどうでしょう。
スループットキャパシティを256MBpsに変更します。
バックアップからボリュームをリストアします。
56分でリストアが完了しました。512MBpsの場合は1時間16分だったので、243MBpsとかなり速いです。クライアントアクセスなど、他処理を行っていない状況においては、スループットキャパシティがリストア速度に与えるはそこまで大きくないのかもしれません。
リストア完了後のFSxNファイルシステムのパフォーマンスのメトリクスは以下のとおりです。
ネットワークスループットおよびディスクスループット、ディスクIOPS、CPUをフル活用していますが、128MBpsの場合と比べると余力があるように見えます。
ストレージ使用量の推移を確認します。
注目すべきはメトリクスは以下のとおりです。
- 赤 : FSxNファイルシステム全体のストレージ使用量
- 緑 : FSxNファイルシステム全体のキャパシティプールストレージの使用量
- 青 : FSxNファイルシステム全体のSSDのサイズ
- 紫 : スループットキャパシティ128MBpsでリストアしたボリュームのキャパシティプールストレージの使用量
- 茶 : スループットキャパシティ128MBpsでリストアしたボリュームのSSDの使用量
紫よりも茶の増加スピードが速いですね。こちらもキャパシティプールストレージへの階層化が間に合っていないようです。そして、リストアデータをSSDかキャパシティプールストレージのいずれかの階層に書き切ったタイミングで、SSDに残っているデータをキャパシティプールへ階層化していることが分かります。
最後にスループットキャパシティごとのリストア実行時間をグラフに記してみました。
赤の増加スピードはいずれのスループットでも大きく変わりありませんね。ただ、キャパシティプールストレージにスムーズに階層化でき、SSDへの圧迫が少なかったのは512MBpsの場合のみです。
SSDはFSxNファイルシステムデプロイ後、増やすことはできますが、減らすことはできません。リストア時にSSDの空きが少ないからといって、SSDを増やしてしまうと、今後増強したSSDのコストを払い続ける必要があります。
リストア時はスループットキャパシティを512MBps以上にしてあげ、スムーズに階層化が進むようにしてあげる方がトータルコストは安くなるかもしれません。
512MBpsの場合は15%から20%ほど余裕を持っておけば安心そうです。つまり、800GiBの場合は120GiBほどの空きがあれば良いでしょう。
WAFLのメタデータとしてデータの3%から7%ほどがSSD上で消費されます。WAFLメタデータについては以下記事をご覧ください。
800GiBの場合は実際メタデータとして消費されるのは56GiB程度ですが、たまのスパイクを捌く余地が必要です。また、以下AWS公式ドキュメントで紹介されているとおり、SSDの使用率が98%以上となると階層化が行われなくなります。
=98% SSDのストレージ階層使用率 – SSDストレージ階層が 98% 以上の使用率になると、すべての階層化機能が停止します。ストレージ階層からの読み取りは引き続き可能ですが、階層への書き込みはできません。
512MBpsだからといって、SSDの空きが全くなくても良いとは限らないということです。
クライアントアクセスなど、他処理を行っていない状況においては、スループットキャパシティがリストア速度に与えるはそこまで大きくないのかも
Amazon FSx for NetApp ONTAPにおいてスループットキャパシティがボリュームバックアップからのリストア速度に影響を与えるのか確認してみました。
結論としては、クライアントアクセスなど、他処理を行っていない状況においては、スループットキャパシティがリストア速度に与えるはそこまで大きくないように思えます。
ただし、先述したとおり、階層化の速度やFSxNファイルシステムに与える負荷には大きな影響を与えます。リストア時は一時的にスループットキャパシティを増強してあげるといったことをしてあげると、スムーズなリストアができるでしょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
